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DETAILED ACTION 



1. 



Claims 1-26 are pending. 



Oath/Declaration 



2. 



The Oath / Declaration was received 16 April 2004. 



Specification 



3. Per Applicants request 16 April 2004 the Specification has been amended. Per 
Applicant's request 24 May 2004, the title has been amended. 

4. The disclosure is objected to because of the following informalities: See [0079], page 19, 
line 16, recites "The node 305. . should be -The node 302. . . - Change '305' to 302'. 

Appropriate correction is required. 



5. The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) because they 
include the following reference character(s) not mentioned in the description: 

Fig. 9, #91 1, #912, #913, #914, & #915 

6. Corrected drawing sheets in compliance with 37 CFR 1. 121(d), or amendment to the 
specification to add the reference character(s) in the description in compliance with 37 CFR 

1 . 121(b) are required in reply to the Office action to avoid abandonment of the application. Any 
amended replacement drawing sheet should include all of the figures appearing on the immediate 
prior version of the sheet, even if only one figure is being amended. Each drawing sheet 
submitted after the filing date of an application must be labeled in the top margin as either 
"Replacement Sheet" or "New Sheet" pursuant to 37 CFR 1.121(d). If the changes are not 



Drawings 



Application/Control Number: 10/728,370 
Art Unit: 2191 



Page 3 



accepted by the examiner, the applicant will be notified and informed of any required corrective 
action in the next Office action. The objection to the drawings will not be held in abeyance. 

Claim Rejections -55 USC §103 

7. The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

8. Claims 1-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over US Patent 
5,754,858 to Broman et al., in view of US Patent Application Publication 2003/0217193 Al to 
Thurston et al. 

Per claim 1 : 

A method of a development and build environment for packaged software delivery in a 
distributed network of nodes, the method comprising the computer-implemented steps of: 
Broman disclosed a 'method' (col. 23, line 31-col. 24, line 40) for "customizable automated 
application project generation (col. 4, lines 65-66) (development and build environment). 
Broman disclosed the 'network' suitability at col. 20, lines 52-63. 

-compiling source code files into executable file modules; 

Broman disclosed compiling source code at col. 6, lines 20-22, "The writer builds. . .from the 
source files. . .using a compiler. . ." 
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-wherein a module contains an image for a process or a dynamically linked library (DLL); 
Broman disclosed dynamically linked libraries at col. 6, lines 27-32, "... links the object 
code. . .and RES files together into a dynamic link library. 

-creating a software package that comprises at least one module; 

Broman disclosed (Col. 6, lines 36-37) the custom application project generator creating the 
application project (software package comprising at least one module). 

-wherein packages are created based on features/characteristics or purpose; 

Broman disclosed, as an example, (col. 8, lines 5-10) the package may be language specific 

(feature / characteristic / purpose). 

-creating metadata for a module that includes, but is not limited to, information such as the 
module's: binary signature, name, directory path, and characteristics; 

Broman disclosed (col. 7, line 55), as an example, a 'name' may be created. Also, col. 11, lines 
47-54, disclosed a services module generates a file named by destination- filename (name) which 
can contain a path (directory path). 

-inserting the module's metadata into the software package; 

Broman disclosed a 'newproj.inf template (col. 11, line 39) that contains created directories, 
whereby the directories are filled by the services module (col. 11, line 49). The services module 
lists files used to build the application (col. 11, lines 60-67). 
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-wherein a module can provide and use at least one API; 

Broman disclosed (col. 8, lines 38-48), as an example, the project generator and services module 
generate using templates (resource files - text or binary),where the binary files contain user 
interface components (APIs). 

Regarding the following limitations, Broman was suggestive of 'dependency information'. 

-gathering application program interface (API) dependency information for each module; 
Broman disclosed (col. 8, lines 25-28 & 44-45) a services module that presents a sequence of 
options for selection, suggestive of dependency compliance. 

-collecting dependencies documented in module specifications. . . ; 

Broman disclosed (col. 10, line 30) application project options, suggestive of dependencies. 
Also Broman disclosed (col. 11, lines 63-67) make files which list source code files that must be 
compiled (considering dependencies) to build the application. 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

Broman disclosed (col. 17, lines 1-24) template processing directives for the document where the 
module build inherently includes API names and versions (bitmap data for user interface 
components copied into the project-col. 8, lines 38-48) 
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Broman was only suggestive of 'dependency 5 information, and failed to disclose 'metadata'. 
However, Thurston, more specifically disclosed metadata [0008-0009] to control installations 
and dependency information placed into 'constraints' that must be satisfied into a header. See 
FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including version 
number, names of dependent devices, size and checksums, and digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman' s invention to include additional details in the component header 
such as names, versions, and dependency constraints, as disclosed by Thurston, because such 
information contained in a header file as meta data is useful for conveying relevant information 
when delivering software for installation. Thurston was motivated (Thurston -[0010]) to provide 
updates to support new and different types of devices in a manner to simplify development and 
maintenance. 

Per claim 2: 
-providing a linker; 

Broman disclosed a linker. See FIG. 2, #72 & #88. 

-wherein said linker creates a list of dependent modules for a given process or DLL module and 
places the list.... 



Application/Control Number: 10/728,370 Page 7 

Art Unit: 2191 

Broman disclosed (col 8, lines 5-10 & 25-28) selectable option steps and selectable language 
resources, suggestive of consideration to dependencies. The services module copies (col. 11, 
lines 55-60) template information to the project. Col. 11, lines 63-67, disclosed a 'make file' 
which lists source code files that must be compiled to build (list of dependent modules for a 
given process) the application. 

Broman was only suggestive of 'dependency 5 information, and failed to disclose placing 
information into the 'metadata'. 

However, Thurston, more specifically disclosed metadata [0008-0009] to control installations 
and dependency information placed into 'constraints' that must be satisfied into a header. See 
FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including version 
number, names of dependent devices, size and checksums, and digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman' s invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 3: 

-creating metadata for each API; 
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Broman disclosed (col. 9, lines 20-55) that a user is presented with options for creating an 
application project. The project generator and services module generate the application project 
using the template files / resource files. Template files / resource files contain text and binary 
files and macros and directives, which determine the content of the source files in the application 
project (provides metadata type information). Broman disclosed (col. 10, lines 3-12 & 31-33) 
'directives' guide the production of the application project, through a confirm. inf template. 

-inserting the API metadata into the software package; 

Broman disclosed (col. 11, lines 17-21) "The newproj.inf template contain the instructions 
(metadata type information inserted into package) that the services module uses to construct the 
application project. The instructions are statements, directives, and macros that work together to 
describe the structure of the application project." 

Regarding the limitation: 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
Broman was suggestive of metadata included in the created application project, but failed to 
explicitly disclose metadata and contents. However Thurston disclosed metadata stored in a 
header portion [0008-0009] to be used to control installation of code. Thurston disclosed the 
header data could include a name, version, size, checksum, digital signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman 5 s invention to include additional details of metadata in the 
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component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 4: 

Bronson failed to disclose: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 

However Thurston disclosed metadata stored in a header portion [0008-0009] to be used to 
control installation of code. Thurston disclosed the header data could include a name, version, 
size, checksum, digital signature (binary signature). Details including name, version, size, 
checksum contribute to a unique binary signature. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 
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Per claim 5: 

Bronson failed to specifically disclose: 

-creating metadata for a package that includes, but is not limited to, information such as the 
packaged: name, build date, and characteristics; 
-inserting the package metadata into the package. 

However Thurston disclosed metadata stored in a header portion (inserting pagkage metadata) 
[0008-0009] to be used to control installation of code. Thurston disclosed the header data could 
include a name, version, size, checksum, digital signature (binary signature). Details including 
name, version (build date), size, checksum (characteristics) contribute to a unique identity. 

Therefore, it would have been obvious, to one of ordinary skill in the art, at the time of the 
invention to modify Broman's invention to include additional details of metadata in the 
component header, as disclosed by Thurston, because such information contained in a header file 
as metadata is useful for conveying relevant information when delivering software for 
installation. Thurston was motivated (Thurston -[0010]) to provide updates to support new and 
different types of devices in a manner to simplify development and maintenance. 

Per claim 6: 

A method of a development and build environment for packaged software delivery in a 
distributed network of nodes, the method comprising the computer-implemented steps of: 
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-compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 

-creating a software package that comprises at least one module; 

-creating metadata for a module that includes, but is not limited to, information such as 

the module's: binary signature, name, directory path, and characteristics; 

-inserting the module's metadata into the software package; 

-gathering application program interface (API) dependency information for each module; 
-wherein a module can provide and use at least one API. 

See rejection of limitations as addressed in claim 1 above. 

Per claim 7: 
-providing a linker; 

-wherein said linker creates a list of dependent modules for a given process or DLL module and 

places the list in the module's metadata. 

See rejection of limitations as addressed in claim 2 above. 

Per claim 8: 

-collecting dependencies documented in module specifications and placing them into the 
module's metadata; 
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-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
Per claim 9: 

-creating metadata for each API; 

-inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 
See rejection of limitations as addressed in claim 3 above. 

Per claim 10: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 

Per claim 1 1 : 

-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 12: 
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-creating metadata for a package that includes, but is not limited to, information such as the 

package's: name, build date, and characteristics; 

-inserting the package metadata into the package. 

See rejection of limitations as addressed in claim 5 above. 

Per claim 13: 

An apparatus for a development and build environment for packaged software delivery in a 
distributed network of nodes, comprising: 

Bronson disclosed a 'system' (apparatus) (col. 4, lines 64-66) providing an automated 
application project generation (a development and build environment). 

-means for compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 

-means for creating a software package that comprises at least one module; 

-means for creating metadata for a module that includes, but is not limited to, information such 

as the module's: binary signature, name, directory path, and characteristics; 

-means for inserting the module's metadata into the software package; 

-means for gathering application program interface (API) dependency information for each 

module; 

-wherein a module can provide and use at least one API. 
See rejection of limitations as addressed in claim 1 above. 
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Per claim 14: 
-a linker; 

-wherein said linker creates a list of dependent modules for a given process or DLL module and 

places the list in the module's metadata 

See rejection of limitations as addressed in claim 2 above. 

Per claim 15: 

-means for collecting dependencies documented in module specifications and placing them into 
the module's metadata; 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
Per claim 16: 

-means for creating metadata for each API; 

-means for inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the API's name and version. 

See rejection of limitations as addressed in claim 3 above. 

Per claim 17: 

-means for calculating a binary signature for each module and inserting the binary signature into 
the respective module's metadata; 
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-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 

Per claim 18: 

-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 19: 

-means for creating metadata for a package that includes, but is not limited to, information such 
as the package's: name, build date, and characteristics; 
-means for inserting the package metadata into the package. 
See rejection of limitations as addressed in claim 5 above. 

Per claim 20: 

A computer-readable medium carrying one or more sequences of instructions for a development 
and build environment for packaged software delivery in a distributed network of nodes, which 
instructions, when executed by one or more processors, cause the one or more processors to 
carry out the steps of: 

-compiling source code files into executable file modules; 

-wherein a module contains an image for a process or a dynamically linked library (DLL); 
-creating a software package that comprises at least one module; 
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-creating metadata for a module that includes, but is not limited to, information such as the 
module's: binary signature, name, directory path, and characteristics; 
-inserting the module's metadata into the software package; 

-gathering application program interface (API) dependency information for each module; 
-wherein a module can provide and use at least one API. 

This is a 'computer readable medium' version of claim 1. See FIG. 2 where the instructions for 
development are shown located on a system. See rejection of limitations as addressed in claim 1 
above. 

Per claim 21: 
-providing a linker; 

-wherein said linker creates a list of dependent modules for a given process or DLL module 

and places the list in the module's metadata. 

See rejection of limitations as addressed in claim 2 above. 

Per claim 22: 

-collecting dependencies documented in module specifications and placing them into the 
module's metadata; 

-wherein the dependencies documented in each module lists API names and versions that the 
process or DLL depends on. 

See rejection of limitations as addressed in claim 1 above. 
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Per claim 23: 

-creating metadata for each API; 

-inserting the API metadata into the software package; 

-wherein metadata for an API includes, but is not limited to: the APFs name and version. 
See rejection of limitations as addressed in claim 3 above. 

Per claim 24: 

-calculating a binary signature for each module and inserting the binary signature into the 
respective module's metadata; 

-wherein each unique version of a module will have a unique binary signature. 
See rejection of limitations as addressed in claim 4 above. 

Per claim 25: 

-packages are created based on features/characteristics or purpose. 
See rejection of limitations as addressed in claim 1 above. 

Per claim 26: 

-creating metadata for a package that includes, but is not limited to, information such as the 
package's: name, build date, and characteristics; and inserting the package metadata into the 
package. 

See rejection of limitations as addressed in claim 5 above. 
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Conclusion 

9. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Mary Steelman, whose telephone number is (571) 272-3704. The 
examiner can normally be reached Monday through Thursday, from 7:00 AM to 5:30 PM If 
attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Tuan 
Q. Dam can be reached at (571) 272-3695. The fax phone number for the organization where 
this application or proceeding is assigned is 703-872-9306. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Mary Steelman 
06/26/2005 




